前言：發版不就是打個版號、寫個 changelog 嗎？

「產生 changelog、跑一次測試、打包上傳，這些步驟都很機械化，全部交給 AI 自動化不就好了？」

聽起來合理，但這系列一路走下來，已經看過太多次「機械化的步驟」跟「機械化的判斷」被混為一談的案例——issue triage 是機械化步驟、優先序判斷不是；PR review 檢查清單是機械化步驟、要不要合併不是。Release 流程也是同一種結構：把「產生 changelog」自動化很安全，把「這個版本該不該發」也自動化，就完全是另一回事了。

今日目標

• 分清楚 release 流程裡哪些步驟是機械化的、哪些是判斷
• 用這個專案真實的發版紀錄，具體看一次發版節奏長什麼樣
• 理解「版號怎麼跳」本身也是一種需要人判斷的溝通行為，不只是技術規則
• 建立「AI 準備好一切、人按下最後一個核准鍵」這個分工模型

先看真實的發版節奏：這個專案怎麼發版

查一下 PHPUnit & Pest Test Explorer 這個專案最近的 release 紀錄，會看到一個很典型的維護節奏：版號是連續的 patch release（v3.9.31 到 v3.9.40），發版頻率不固定——有時候隔好幾天才一次，也有同一天內連續發了兩次。

例如 2026-07-13 這天，19:18 發了 v3.9.39，20:57（不到兩小時後）又發了 v3.9.40。v3.9.39 的 changelog 裡一次修了六件事：Test Explorer 的整體測試狀態顯示邏輯、macOS e2e CI 的 socket 路徑問題、README 徽章顯示問題、底層剖析器版本升級帶來的解析行為調整、Pest only() 語意的修正、arch() 失敗訊息裡的連結遺失問題。v3.9.40 則以功能新增為主（Pest 的 todo()/skipOnCi() 顯示邏輯），外加一項圖示跟描述文字互相矛盾的小修正。

這個真實紀錄本身就說明了一件事：發版不是「累積到某個時間點就打包」，是根據「現在有沒有值得讓使用者拿到的東西」做的判斷——有時候一次修好幾個問題才發、有時候一個功能做完就立刻發，這個節奏沒有寫在任何自動化規則裡，是維護者當下對「這批改動夠不夠成熟」的判斷。

Release 流程裡哪些部分適合自動化

看清楚這個節奏之後，再回頭看流程裡的機械化步驟：

• 產生 changelog 草稿：從這次要發版範圍內的 commit 訊息或 merged PR 標題整理出條列式清單，這件事 AI 做得又快又準確，只是格式跟分類（Added/Fixed/Changed）需要規則。
• 版號建議：根據 Semantic Versioning 規則，判斷這批改動裡有沒有破壞相容性的變更、有沒有新功能、還是純粹修 bug，對應到 major/minor/patch 哪一級——這是可以自動判斷的邏輯規則。
• 打包前的檢查清單：完整測試套件跑過、lint 通過、版本號在設定檔（package.json 這類）裡確實更新到位——這些都是可以寫成自動化腳本檢查的機械式步驟。

用一組對照來看這個差異：

❌ 把「發版」整個流程自動化：
「測試套件跑過就自動打版號、自動發版、自動推播更新通知。」
→ 沒有留給任何人一個「等一下，這批改動真的準備好了嗎」的介入點，
  一旦某個改動的影響比預期大，使用者已經拿到手了

✅ AI 準備、人核准：
「AI 產生這次要發版範圍的 changelog 草稿跟版號建議，
 列出跑過哪些檢查、有沒有已知但還沒解決的相關 issue，
 維護者看過這份摘要，決定要不要現在發、要不要先調整版號級別。」
→ 機械化的準備工作交給 AI，最後一個「發不發」的按鈕留給人

AI 可以幫你把「這次能發版」的所有客觀證據準備齊全，但『現在是不是該發』這個判斷，牽涉到使用者體驗的時機、這批改動彼此之間夠不夠一致、有沒有已知問題值得再等一下——這些都不是能從測試結果裡直接讀出來的答案。

版號怎麼跳，也是一種溝通行為

有個容易被忽略的細節：版號本身也是在跟使用者溝通。同一批改動，標成 patch（3.9.40）還是 minor（3.10.0），傳達給使用者的訊號不一樣——後者暗示「這裡有值得注意的新東西」，前者暗示「照常升級，不用特別留意」。

AI 可以照 Semantic Versioning 的規則機械地判斷「這批改動裡有沒有新增公開 API」，但「這個新功能重不重要到值得用 minor 版號讓使用者注意到」，是一種溝通判斷，不是純技術規則能決定的。

今日思考題

回想你維護的專案（或你依賴的某個套件）最近一次發版：那次版號的跳法，是嚴格照著 semver 規則來的，還是維護者刻意選擇了一個更能傳達訊息的版號？

今日重點回顧

• Release 流程裡的機械化步驟（changelog 草稿、版號建議、打包前檢查）適合交給 AI 準備
• 真實發版紀錄顯示：發版節奏是根據「這批改動夠不夠成熟」判斷出來的，不是固定週期
• 版號怎麼跳本身是一種對使用者的溝通行為，不只是技術規則
• AI 準備所有客觀證據，但「現在該不該發」的最後判斷留給人

明日預告

明天用一個案例，具體看一次發版前 AI 準備好了 changelog 跟版號建議，卻漏掉了什麼檢查項——這正是「AI 準備齊全」跟「真的準備好了」之間的落差。